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APL INA Book! 
Christopher H. Lee 


[This appeared on CompuServe on May 11, and has 
been edited for publication. -Ed] 


Hooray! We at Manugistics are proud to announce the 
publication of THE FIRST EVER APL textbook with a 
complete, fully-functional APL*PLUS PC interpreter 
included! Maurice Delois, who taught APL at Laval 
University in Quebec, Canada, and is now developing 
applications in the education world, is the author and 
publisher of Introduction to APL*PLUS PC, the first 
offspring of our Special Edition program. The book is 
available from EducAPL Inc, 1120 av du Parc, Quebec, 
Quebec, Canada, GIS 2W7 (Fax: 418-683-3110). The 
price is $30 each for 1-5 copies going down to $20 when 
purchasing more than 5 and each copy includes a disk 
with the full APL*PLUS PC interpreter. Shipping is $5 
per copy in North America. Here is the ideal introduction 
to APL for your friends, relatives and co-workers! Now 
wouldn't you like to be featured in the next message like 
this? It costs nothing to include APL*PLUS PC in a 
published work. If you're working on a book, just contact 
us and we'll be happy ts help. Ultimately, nothing will 
grow APL like easy, cheap access and you can help 
provide it. | 


The version included is the APLSE.EXE (SE stands for 
special edition). This is the Version 10.1 interpreter; 
object sizes of more than 64K, virtual workspaces, and 
one or two other minor facilities (like terminal mode) are 
turned off. It comes up with a full-screen banner that 
can't be removed. Plus, of course, there is no runtime 
with it. The only extra files beyond the interpreter are 
aplfont files (including herc and softchr) and the basic 
user command file. Everything else has to be provided 
by the author. This particular disk includes a bunch of 
(what look like pretty neat) workspaces that go with the 
lessons in the book. It is thought that a French Language 
version was issued concurrently with the English release 
- good news for Quebecis and EuroFrench. If this 
catches on, we might see it taught in schools! Current 
APLers are more than welcome to jump on the 
bandwagon and produce their own books - not 





necessarily on APL, but on any subject that uses APL as 
the means for experimenting. 


In Memoriam 


John Pribyl 


Editor and Publisher, 
North Texas PC News 


October, 1981 through May 21, 1993 
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1994 SYMPOSIUM ON APPLIED COMPUTING 
(SAC'94) 


Special Interest Group APL 
Call for Papers and Participation 
March 6-8, 1994 - Phoenix Civic Plaza 


Conference Chair 
Hal Berghel University of Arkansas 
Program Co-chairs 
Terry Hengl 
Joseph Urban 


Knowledge Technology, Inc. 
Arizona State University 


Conference Coordinator 
Edmund Deaton San Diego State University 
APL Track Chair 

Christopher H. Lee Manugistics, Inc. 


SAC Steering Committee 


Elias Awad Univ. of Virginia (SIGBIT) 
Hal Berghel Univ. of Arkansas (SIGAPP) 
George Hedrick Oklahoma State University 
Richard Hetherington Univ. of Missouri-KC 
John Hightower Cal State (SIGCUE) 
Abe Kandel Univ. of South Florida 
S. Lakshmivarahan Univ. of Oklahoma 
Irving Montanaz Brookhaven Labs (SIGFORTH) 
William Poucher Baylor University 
Roy Rada University of Liverpool (SIGBIO) 
Lynne Shaw Consultant (SIGAPL) 
John Talburt Univ. of Arkansas-LR 
Glenn Thompson AMOCO 
Elizabeth Unger Kansas State (SIGSMALL/PC) 
Joseph Urban Arizona State University 
Roger Wainwright Univ. of Tulsa 
Kam-Fai Wong ECRC SAC '94 


SAC is the annual conference of the ACM Special 
Interest Groups (SIGs) on Applied Computing 
(SIGAPP), APL (SIGAPL), Biomedical Computing 
(SIGBIO), Business Information Technology (SIGBIT), 
Computer Uses in Education (SIGCUE), FORTH 
(SIGFORTH) and Small and Personal Computers 
(SIGSMALL/PC). For the past nine years, SACs have 
become a primary forum for applied computing 
practitioners and researchers. Once again, SAC '94 will 
be held in conjunction with the 1994 ACM Computer 
Science Conference in Phoenix. This year, each of the 
SIGs will have its own track within the conference. 
Although papers and proposals for panels, tutorials and 
workshops which deal with the conference themes, 
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STRATEGIC TECHNOLOGY TRANSFER and 
INTELLIGENT BUSINESS APPLICATIONS, are 
especially encouraged, papers which deal with all areas 
of applied computing are solicited. 





LETTERS TO THE EDITOR 


APL93 Russian Fund 

Box 384 Adelaide Street PO 
Toronto, Ontario M5C 2J5 
Canada 


28 April 1993 


To all APL Local Groups: 
The APL93 Russian Fund grew to nearly US$3,000 by 
the end of February, but there have been no contributions 
for two months. Contributions to date can be represented 
geographically as follows: 


Location Amount Contributors 
California US$325 4 
Connecticut US$ 50 1 
Hawaii US$100 1 
Illinois US$100 l 
Kentucky US$ 50 1 
Massachusetts US$100 l 
New Jersey US$300 2 
New York US$295 5 
Texas US$ 60 1 
Australia US$100 1 
Belgium US$200 1 
Canada Cdn$600 4 
England £ 75 l 
France US$100 1 
Japan US$300 1 
Switzerland Cdn$500 l 


The APL93 Program Chair has now accepted papers 
from four Russians for the APL93 Proceedings, three of 
whom cannot attend APL93 without financial support 
(the fourth is living and working in the United States). 
The first priority of the APL93 Russian Fund is to bring 
these three contributors, plus one of the APL92 
organizers, to Toronto. Another group of Russians have 
written an expert system in APL, which they would like 
to demonstrate. It would also be nice to bring some of 
the SovAPL founders as well as APLers from the other 
former Soviet Republics. We would like to bring 8 to 10, 
if possible. But this would mean much more money -- 
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perhaps US$20,000 -- and fairly soon, since the getting 
of visas can be time-consuming. 


The average Russian income is about US$25, but Russia 
is not just another Third World country. It is a country 
of many highly educated people and many very skilled 
scientists. In a country where chess is the national sport 
and computers must be adapted to a different alphabetic 
system, APL has a good chance to grow and flourish. By 
helping Russian APLers to be a part of our community, 
they can acquire the resources to promote the use of APL 
as part of their new, emerging society. 


Some people question why there should be a fund for 
Russians, specifically, rather than for Eastern Europeans, 
students, APLers from other poor countries, or APLers 
under economic hardship. This fund was an act of 
gratitude for the APL92 Conference in Russia -- and for 
the groundbreaking efforts that made that conference a 
reality. The fund is a recognition that the new 
connections that have been made should not be lost. 


The original objectives of the APL93 Russian Fund were 
modest. In fact, there were moments in the Fall of 1992 
when one of us (Ben Best) had fears that he would have 
to top the fund from money from his own pocket to pay 
for even one Russian to attend APL93 (after having 
already spent hundreds of dollars on postage). If this 
fund is successful, however, it can be the precedent for a 
"World APL Conference Attendance Fund". It may be 
that we have colleagues in Eastern Europe, India, China, 
South America, etc., who would submit papers and 
attend our conferences if they were not subject to such 
severe economic constraints. 


Donations from those in the United States should be 
tax-deductible through the ACM. People from other 
countries will have to live with the reality that they have 
given from the heart and can expect only gratitude in 
return. It is appreciated. If you can contribute to this 
effort, please do. Please send as much as you feel you 
can afford to the address shown at the top of this letter, as 
soon as possible. And please circulate this request to 
others in your local APL group. 


Sincerely, 


Robert Bernecky 
ACM APLSIG Liaison 


Benjamin Best 
Treasurer APL93 
(ben.best%canrem@uunet.ca) 
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IBM APL2 WORKSTATION PROMOTION 


For a limited time only, customers can acquire the 
following APL2 software packages at discounts of 50% to 
70% off the One-Time Charge (OTC). In addition, 
eligible customers can enroll in the Skill Dynamics APL2 
Programming Course at 20% off the normal enrollment 
fee. 


Eligible programs, prices, and discounts are as follows: 
Model OTC 5/4/93 


Discount New OTC 


APL2 for the RISC System/6000 V1.1, (5765-012): 


2XX $1,050 50% $525 
3XX $2,100 50% $1,050 
SXX $4,200 50% $2,100 
900 $8,400 50% $4,200 


APL2 for the PC/DOS V1.02, Pid#: 5799-PGG, PRPQ#: 
RJ0411 
ALL $630 70% $189 


AGSS - A Graphical Statistical System, AISPO Pid#: 
5764-010*, PRPQ#: P04245 
ALL $500 50% $250 


Orders for the APL2 software must be placed on or 
before October 29, 1993. The Date of Installation, as 
defined in the IBM Customer Agreement, must be on or 
after May 4, 1993, but no later than December 31, 1993. 
Customers can place orders through their IBM 
representative or by calling 1-800-IBM-CALL and 
specifying Department S60-IL when placing the order. 


The APL2 Programming Course (CK36150C) is limited 
to one offering per qualifying location (defined as a 
single location with a single mailing address). 


To be eligible for the 20% discount on the course, 
customers must acquire at least one of the above APL2 
programs, and have proof of acquisition when they sign 
up for the course. The course must be completed by 
March 31, 1994. 


This promotion, in which all customer types can 
participate, cannot be combined with any other discounts 
or allowances. Customers with a volume or special bid 
commitment can take advantage of this promotion or 
their volume/special bid discount. Products acquired 
under this promotion, however, will count toward their 
commitment. 


IBM reserves the right to modify or withdraw this 
promotion at any time. 
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For ordering or additional information on this promotion, 
call 1-800-IBM-CALL or send a fax to 1-404-238-3442 
and specify Department S60-IL when making the 
inquiry. 

APL2 technical questions can be answered by calling the 


APL2 Helpline at 1-408-463-APL2. For answers to 
AGSS technical questions, call 1-914-784-7563. 


Skill Dynamics prices and schedules can be obtained by 
calling 1-800-IBM-TEACh (426-8322) and specifying 
Department IGAA-IL when making the inquiry. 


Even an APL guru needs a vacation. 
Especially a working APL guru. But if 
you want it to be less expensive and more 
enjoyable, call Mike von Tiesenhausen as 
early in the game as possible to plan it or 
just to dream about it. 


Sundance Travel (214) 352-4650 


Personalized Service for APL gurus 


TIDBITS 


Elections for new officers for SIGAPL of the Association 
for Computing Machinery (ACM) are in progress. 
Candidate information and ballots were mailed from 
ACM headquarters in New York City on May 21, and are 
due back at ACM by June 24. The offices are Chair, 
Vice Chair, Secretary-Treasurer, and three At-Large 
board members. Terms of office are July 1, 1993, 
through June 30, 1995. 


Iverson Software Inc. announces new versions of APL 
and J. We reprint from the May, 1993, ISI newsletter: 


"The new session manager is a single edit window, has a 
Standard menu, supports different fonts, and has 
improved line recall and editing capabilities. You can 
now run multiple copies of APL and J. 
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"The window driver is significantly improved. It 
supports all standard window classes (button, edit box 
listbox, combobox, scrollbar, etc.). It also supports a 
graphics class in which all GDI drawing commands are 
supported, a picture class which can display WMF, BMP, 
and ICO graphic images, and an ole class which can 
display OLE objects that are connected to servers such as 
Msgraph and Paintbrush. Ownerdraw buttons and 
listboxes are also supported. APL and J can act as OLE 
clients and as DDE clients and servers. 


"We have reprinted the second edition of the Sharp APL 
Reference manual. By removing material not relevant to 
the PC and by reducing the font size we were able to 
print it in a single volume with our standard wire 
binding. By increasing print volumes we were able to 
make it available at half the previous price. 


"J - Version 6.2 is the latest version and includes the 
derivative conjunction which is used extensively in the 
new Calculus text. The separate publications for the 
dictionary and introduction have been merged into a 
single book called J: Introduction & Dictionary. This 
text is printed in a larger font, is better integrated, and is 
complete for Version 6.2." 


Both previous and current versions of the Windows APL 
and J products run under the most recent beta version of 
OS/2 2.1 


Iverson Software Inc. can be reached at 33 Major Street, 
Toronto, Ontario, MSS 2K9; and at (416) 925-6096. 





USER Group NEWS 


Atlanta (SEAPL) The May 26 meeting featured Dr. 
Brian Schott and Mr. Ted Randles (Doctoral Candidate) 
of the Georgia State University. The topic for discussion 
was "APL and J Usage in Educational Institutions". 


Sunday, July 25, 1993, is the date for SEAPL's Summer 
picnic. It will be held from 2 PM to 5 PM at Stone 
Mountain Park. Details to follow in the next SEAPL 
newsletter. 


Dallas (SWAPL) The May meeting featured Dr. 
Wai-Mee Ching, of IBM Corporation, who presented the 
current version of IBM's experimental APL-to-C 
translator. See the review beginning on page 7. 
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The June meeting will be held on Tuesday the 1*, at 7:30 
PM, at the DeVRY Institute of Technology, 4250 North 
Beltline Road, Irving, Texas, in Room 218. From 
Highway 114, go two miles south on Beltline. The 
building is located on the east side of the road. 


The June program features Gregg Taylor, who will 
demonstrate the new release of Dyadic Systems' Dyalog 
APL, Version 6.3. Gregg will concentrate on the 
Windows (that is, GUI) capabilities and enhancements of 
this release. 


At this meeting, we will collect contributions to the 
APL93 Russian Fund. See the Ictter on page 3 of this 
newsletter for more information. 


A pre-meeting dinner will be at 6 PM at the Black-Eyed 
Pea restaurant on Beltline Road at Northgate Road, about 
one mile south of DeVRY. Everyone is invited! 


New York (NY/SIGAPL) The May 26 meeting included 
a presentation of IBM's experimental APL-to-C 
translator by Dr. Wai-Mee Ching. The June 23 meeting 
will feature Adam Kertesz talking on "Distributing APL 
Computation". 


Northern California (APL BUG) The May 10 meeting 
featured Curtis Jones and a talk entitled "Inner-Product 


‘Scans for Spirals and Random Bits". Meetings are at 7 


PM at the Syntex Laboratories building A2, Room 1, 
3401 Hillview Avenue, Palo Alto. 


The June 14 meeting will feature Arthur Whitney, of 
Morgan Stanley, talking about "A"; David Liebtag, of 
IBM, will talk about "APL2 Status" on July 12. 


Southern California (SOCAL-SIGAPL) The May 12 
meeting featured Don Scheer of Kay Consulting. Don 
gave a presentation of APL running in a Windows 
environment. 


Toronto The May 17 meeting included a summary and 
update of APL93, presented by Larry Moore, APL93 
Conference Chair. He was assisted by Bob Bernecky and 
Lee Dickey. 





The next meeting will be on September 27, 1993, and 
will include a review of APL93. 


Meetings are on the fourth Monday of each month from 
September through May, excluding December, and are 
held at CIBC's 10* floor lounge in the BCE Place 
building, 161 Bay Street. 
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We just couldn't 
leave well enough 





alone! 


APL*PLUS II Version 5.1 


"Announcing: APL*PLUS li 
-Version 9.1 





| with 3-d Controls! 


E 
l 
| 
| 
i 


APL*PLUS® II for DOS and Windows™ 
just got better! It's now even easier (and a 
lot faster!) to build applications using all of 
the features of Windows 3.1. There's even a 
Software Developer's Kit that shows you 
how to easily add third-party custom 
controls! 


And don't forget that APL*PLUS II is the 
only APL system that provides you with a 
fully-integrated Debugger, Paradox 
Interface, full DDE access, Lotus 





Soul a Toolbarsi————— 


| Bitmaps! 


and dBase Import/Export, optimized 
Assembler functions, the User Command 
Processor, a Numeric Data Editor and the 
most powerful session manager available 
anywhere! 


Get GUIng today! Call Manugistics, Inc. at 
800-592-0050, ext. 625 (in Maryland, dial 
301-984-5123) or Fax 301-984-5094 and get 
the most out of both DOS and Windows 
with APL&PLUS I Version 5.1! 


APL*PLUS is a registered trademark of Manugistics, Inc., 2115 E. Jefferson Street, Rockville MD 20852. 
Other trademarks are the property of their respective owners. 
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DALLAS May MEETING NOTES 


Todd B. Marshall 
Conroe, Texas 


APL has always struggled with a reputation for being 


slow when compared to conventional compiled languages 
like Fortran or C. APL programmers have devoted much 
energy to finding and using coding styles that yield 
acceptable execution speeds. This usually means 
arranging the data so it can be lined up and mowed down 
with little interpretive overhead...avoiding the dreaded 
looping. 


In many cases, programmers have found that the only 
way to achieve acceptable performance is to use other 
languages to implement commonly used programming 
techniques. Removal of extraneous blanks from 
character strings, syntactic searches within strings, table 
lookups, and maintenance of segmented string 
mechanisms are among typical examples. In effect, in so 
doing, skillful coders have been able to extend the 
standard set of APL operators. 


But what if you have to speed up your APL program and 
you don't want to learn another programming language? 
Or what if know that other language but really don't want 
to code in it unless you absolutely have to? 


Enter Wai-Mee Ching stage left. Dr. Ching, a Research 
staff member at IBM's Watson Research Center has just 
the ticket. Since 1985 Wai-Mee and his colleagues have 
been working on schemes to generate efficient code from 
APL code. The early strategies generated 370 assembler 
code from APL source. Recent efforts now produce 
ANSI C code from APL source code. 


So, what you do is write your little algorithm in APL. 
You then pass it through Wai-Mee's translator that 
produces an intermediate code. You then run this 
intermediate code through one of two compilers that 
produce assembler or C code (whichever is your choice). 
This is then assembled or compiled into the machine 
code that actually gets executed. 


And the result runs faster...usually. Wai-Mee reports 
speed improvements ranging from about double to 77 
times (in one case) for the C code. As a mule, the 
assembler code runs faster than the C code...about twice 
as fast. But surprisingly, APL code seems to run faster 
than the compiled code for those examples that make use 
of Boolean matrices. This is because of all the work you 
need to go to pry the bits out of the integer words. 
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Now you're not just going to run that humongous 
inventory control program through Dr. Ching's magic 
and expect a result. There is a restriction or two. 


First, forget about asking for input or producing output 
within your program. Data can get in only through the 
left and right arguments of the primary function header; 
But you must tell its argument rank and type beforehand. 


Second, don't expect to make any rank changes to your 
variables while running. The compiler requires that the 
rank of any variable not exceed 7 and not change within 
the program. Further, you can't use a variable as 
numeric and later use it as character. In some cases you 
can't let it be floating point and then try to use it as an 
integer (indexing for instance). 


Do you like nested arrays? You'll have to wait. Use 
complex numbers? You'll have to wait. Use system 
functions? Not here. And you have to set up your 
branching constructs in one of the several patterns that 
Dr. Ching supports. He will support some of the 
common techniques of using the execute operator to set 
up a branch, but in general, building up strings to 
execute is taboo. 


And finally, unless you're running the result on the 370, 
don't attempt to "name associate" it with your APL code 
and get the best of both worlds...name association isn't 
implemented yet on anything but the mainframe 
platform. 


Mr. Ching’s compiler is implemented in less than 14 
thousand lines of APL code. It runs on the 370, PS/2 and 
RS/6000 platforms. If you would like more information 
you can contact Dr. Ching at the Thomas J. Watson 
Research Center; Yorktown Heights, NY 10598 or by 
E-Mail: at ching@watson.ibm.com. 


SWAPL thanks Dr. Ching for telling us about his 
compiler this month. These meetings just keep getting 
better and better. 





APL User Groups (UNITED STATES) 


The following is a listing of all known cities in the 
United States with active APL user groups, along with 
the name of a person to contact and at least one way to 
contact him/her. Not all user groups have newsletters, 
but all do meet periodically. If you know of any 
additional groups (that would like to be listed), please let 
the editor know at his masthead address. Updates to 
contact information are most welcome. 
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Atlanta, Georgia 
Doc Manges 
991 Creekdale Drive 
Clarkston, GA 30021 
(404) 292-4968 





Chicago, Illinois 
Larry Mysz 
836 Highland Drive 
Chicago Heights, IL 60411 


Dallas, Texas 
Margaret Brooker 
P. O. Box 210367 
Bedford, Texas 76095 
(817) 577-0165 
CompuServe: 73700,2545 
Internet: 73700.2545@compuserve.com 





Hartford, Connecticut 
Bob Pomeroy 
Mass Mutual Life 
1295 State Street 
Mail Drop F465 
Springfield, MA 01111 
(413) 788-8411, ext. 2838 





New York, New York 
Jacob Brickman 
P. O. Box 138 
New York, NY 10185-0002 
(718) 773-4093 


Northern California 
Curtis A. Jones 
228 South 15th Street 
San Jose, CA 95112-2150 
Internet: jonesca@vnet.ibm.com 
Prodigy: CJGHS6A 
FidoNet: 1:143/11 


Southern California 
Roy A. Sykes, Jr. 
Sykes Systems, Inc. 
4649 Willens Avenue 
Woodland Hills, CA 91364-3812 
(818) 222-2759 


Washington, District of Columbia 
John A. Martin 
(301) 497-2698 
fax: (301) 498-8260 
Internet: jmartin@milo.starlab.csc.com 
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APPLICATION NOTES 


Rick Butterworth 
Monterey, California 


This month’s column continucs our discussion of the 
Manugistics APL*PLUS® II Windows interface, sharing 
my experience learning the use of object “instances”. But 
first, some old business. 


Coding Environment 


Index origins are tricky, because once accustomed to 
using a specific origin, it’s easy to overlook 
origin-dependent expressions when switching to the 
lesser-used origin. I switched to origin zero some time 
ago because many expressions seemed to simplify. Well, 
Pll put “index origin” on the list and cover it another 
time. I bring it up now because last month I got nailed (a 
technical expression first used in this Newsletter by Todd 
Marshall) by trying to adapt an APL*PLUS II APLGUI 
form to use a ODIO of zero. My adaptation worked fine 
under v5.1 (beta), but under v5.0 it unceremoniously 
crashed. Granted, I should have tested my form with 
v5.0, but I assumed it would work. Never assume. 


If you downloaded the form from CompuServe or the 
Manugistics BBS (SWAPLO.ZIP) early on, my apologies. 
The latest version (dated 5/21/93 or later) is origin 
independent and runs fine in the origin 1 APLGUI 
environment. Technical staff at Manugistics have 
suggested that an origin-independent version of APLGUI 
might be made available. 


While we are on items to be alert for, be cautious about 
error trapping in your event handlers. The APLGUI code 
expects DELX to be set globally to '#HANDLERFOR 
ODM'. Event handlers are both called by and call 
APLGUI code, meaning your event handlers inherit this 
error handling scheme. This is either good or bad, 
depending on your predilections for error handling. If 
you use the APLGUI scheme, great. If, like me, you use 
another scheme, this presents a small problem requiring 
a work around. Is this beginning to sound like the index 
origin story, or what? 


My point here is twofold. First, an old lesson relearned — 
never assume and test often. The other point is that 
APLGUI could insulate itself better from user's code. 


A Manugistics spokesperson explained that APLGUI and 
user's code were, by the nature of APLGUI, inextricably 
entangled. Issues such as these illustrated some of the 
weaker aspects of traditional APL and name scoping in 
particular. Putting that issue aside, a user wishing to 
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create an environment independent from APLGUIs 
might consider localizing the relevant system variables, 
then using a cover function to Win or other APLGUI 
functions called by the event handler. The cover function 
would localize and set the preempted system variables 
back to the values found when the handler — not the 
cover function — started. (Localized system variables do 
that for you, assume their global values even when 
localized.) In my case, OIO and OELX are candidates. 
A bit busy, but it should work. 


Control Object Instances 


The APL*PLUS II - Windows interface contains the 
concept of instances for both form or control objects. 
The documentation does not contain a formal definition 
of instances, so the following is offered as a working 
definition. An instance is: 


a means for creating duplicate copies of a form or 
control object with unique properties but common 
event handlers. 


Why are instances important? Because they allow, even 
encourage, forms with less code, and as we all know, 
“less is better” when it comes to code. 


Here's how control instances work. Suppose your form, 
say fmApply, contains three lines to be filled in and you 
want to use an edit control object for each. Except for 
their location, size, and assorted other properties, these 
edit controls should respond in a similar fashion to any 
event that might occur to them. You could use distinct 
controls, named edLinel, edLine2, and edLine3, and 
write three APL routines for checking user's input, 
fmApply_edLine1(2, 3)_Change. If the 
nature of your checking were the same for each line, 
instances would provide a better design. By making the 
three edit control objects instances of the same object 
however, say edLine, there is only one event handler for 
the Change event, fmApply_edLine_Change. This 
APL function can reference the instance property of the 
edLine control object to determine which line is 
changing. | 


Instance Identification 


Instances are identified by bracketed instance numbers in 
a control's name. Following the above example, use 
edLine{1] (or equivalently edLine), edLine[2], and 
edLine[3] when referencing or setting the controls. This 
format tells APLGUI that you are referring to instances 


_ of edLine. For example, to set the text property in the 


context of the form: 


Win 'edLine(2].text' 'Your name here' 
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The instance is a property of all APLGUI control objects, 
except Menu. (Menu control items may have instances; 
however, see the documentation.) To identify the control 
instance causing an event handler to execute, reference 
its instance property: 


instance <« Win'.instance' 


The above expression relies on the context of the event 
handler to identify the relevant control object and 
consequently the correct instance. In particular, the 
following expression will not return the correct instance: 


Win'edLine.instance' 


Instead, this expression always returns 1, the default 
instance number. 


Instance Numbers 


Instance numbers are integers in the range 1-255, with 1 
effectively the default when omitted. Instance numbers 
need not be dense. There may be gaps in their 
assignment, except that you must use instance 1, 
explicitly or implicitly, and do so before any other. 


A word of caution is in order here. Be sure to create the 
first instance first. (Multiple instance creation is 
discussed below.) Other instances are created as clones 
of instance 1, consequently creating instance number 2 
before 1 is a logical impossibility in the scheme of things. 
The APLGUI doesn't always react gracefully to these 
sorts of procedural errors, and I have been locked out of a 
form. This can also happen by deleting the first instance 
while others still exist on the form. After the first 
instance is established, further instances may be 
established in any sequence from the set 2-255. This bit 
of asymmetry comes about because instance 1 is 
effectively a master from which other instances are 
Cloned at creation. 


An Example — fmCallGetFileName 


Figure 1 illustrates a form with several examples of 
control instancing. 





Ac [flag] WGrtOpenFleName (dit filename ext ttle filter finde x ceatdonty) ug 
Defaukt Dir FileName Default Extent Fikers (select detaulj ReadOnly 


es ne ere ro 


[ +1 = R/O Bex Checked I” +4 = Hide Read Only Ck Box 

I #256 = Invalid Characters Okay F #512 = Allow Multiple Selections 

[7 +2048 = Valid Paths Only F +4096 = Existing Files Only 

[I #8182 = Notify if file nonexistent I” #32768 = Ne RJO fiag = 0 


es leNam 
@ Open 
O Saveas 
l 


Fig 1. fmCallGetFileName 
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The form illustrated above exercises an APL function to 
invoke the Windows common user dialogue requesting a 
filename from the user. See last month's column for a 
discussion of the form. 


Referring to figure 1, the three edit controls labeled 
Default Dir, FileName, and Default Extent are 
instances of edit control edDefault. There are no form 
specific event handlers; control instancing in this case 
simply lends organization to the form. There are two 
other examples of control instancing however, the eight 
check boxes ckFlag[1],.... ckFlag[8], defining the flag 
variable, and the two radio buttons, opCall[1] and 
opCall[2], selecting between the Open and SaveAs 
filename query. 


Establishing Multiple Instances of a Control Object 


Once it’s determined that a set of controls are candidates 
for instancing, the question of how to create multiple 
instances arises. There are two approaches discussed 
here: (1) the Wed editor, and (2) make functions. 


If you are creating the form using the Wed editor, 
establish controls using the bracket naming convention. 
As control objects are added to the form, explicitly name 
the controls, e.g. ckFlag[1], ckFlag[2],... , by entering the 
name property directly in the Wed editor. (Be sure to 
create instance | first, after which numbers need only be 
unique.) 


If the controls are already set on the form and you wish to 
rearrange their instance numbers, changing the instance 
property is slightly more convenient. Simply click on the 
control, then identify the instance property on the edit 
bar and enter the new instance number. If you like to 
live dangerously, you can even abandon instance 1, but I 
don't recommend it. 


Another approach to creating multiple instances is make 
functions: APL functions which create from scratch a 
form by issuing calls to the Win function. You can think 
of make functions as batch form creation procedures. 
Here are the first few lines of the make function for the 
form fmCallGetFileName illustrated in figure 1. We 
stick to the naming convention for event handlers and 
methods, however “Make” is neither. 


fmCallGetFileName_Make;data;wSelf 

[1] a Created by Wmake, except where 
noted. 

[2] 

[3] Win 'fmCallGetFileName[]:Delete' 

C4] | 
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[5] wSelf<«Win 
'fmCallGetFileName:New' 'Form' 

C6] Win '.caption' 'R <- [flag] 
WGetOpenFileName (dir filename 
ext title filter findex 
readonly)' 

[7] Win '.border' 113 

[8] Win '.where' 7.5625 0.5 

[9] Win '.size' 18.125 77.625 

[10] Win '.visible' 1 

[11] 

[12] wSelf<«<Win 'bnCall.New' 'Button' 

[13] Win '.caption' 'Call' 

[14] Win '.where' 16 64 1.5 12 


The make function begins by deleting all existing 
occurrences of the form and creating the form new. The 
caption property refers to the title bar for the form and 
the button face for the control bnCall. Positions used to 
set the where property are measured much like character 
screen fields, by their distance down and to the right of 
the window's client area northwest corner, followed by 
their height and width. The default units used here are 
average character heights and widths for the default font. 


The code establishing the eight check boxes as instances 
is as follows: 


[31] wSelf«Win 'ckFlag[1].New' 
'Check' 

[32] Win '.caption' '+1 = R/O Box 
Checked ' 

[33] Win '.enabled' 0 

[34] Win '.where' 4 21.5 28 

[35] 

[36] wSelf-Win 'ckFlag[2].New' 
'Check' 

[37] Win '.caption' '+4 = Hide Read 
Only Ck Box' 

[38] Win '.where' 4 38 1.5 30 

[39] Win '.enabled' 1 a Manual 

C40] Win '.tab' 7 


[72] wSelf«Win 'ckFlag[8].New' 
'Check' 

[73] Win '.caption' '+32768 = No R/0' 

[74] Win '.where' 8.5 38 1.5 18 

[75] Win '.enabled' 1 a Manual 

[76] Win '.tab' 13 
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The check boxes are established as instances of the 
control ckFlag by this make code. They have unique 
captions and positions on the form. Two additional 
properties are set for each instance — enabled and tab. 
We wish the first check box to be initially not enabled, 
but as each subsequent instance is a clone of the first, the 
make function must explicitly enable each one. 


Tabs, ignoring the sign, are dense sets of integers 
beginning from 1 and governing the tab order among 
control groups. Negative runs including the preceding 
positive tab define a tab group, and the tab order within a 
group defines the cursor sequence within the group. The 
first instance of ckFlag is automatically assigned tab 6. 
The make function assigns sequential but negative tab 
values to the remaining check flags so that the tab key 
moves to and from the eight check boxes as a group. 


Only one event handler is necessary for the ckFlag 
control, called whenever one of the eight check boxes is 
clicked. 


fmCallGetFileName_ckFlag_Click;Comput 
eFlag;call;flag 

[1] aVfmCallGetFileName_ckFlag_Click 
- Update the 1Flag caption 

[2] aV Calls: Win Wmsg 

[3] aV Last Update 19 MAY 1993 
22:57:59 

[4] 

[5] a Note: this code serves all (8) 
instances of ckFlag 

[6] 

[7] +(8240DR ODEF Win 
'lFlag.data' )/Err1 

[8] a ComputeFlag now established 

[9] a Syntax: flag+ComputeFlag call 

[10] a 

[11] a call = 1/0 for Open/SavedAs 
variant to the call. 

[12] a flag = integer passed to the 
GetFileName function. 

[13] a 

[14] calleWin 'opCall[1].value' 

[15] 

[16] a Update the caption in 1Flag 
with the composite flag 

[17] 

[18] flag+ComputeFlag call 

[19] Win 'lFlag.caption'('flag = 
', tflag) 

[20] +0 

[21] 

[22] Erri: 
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[23] 0 OpWmsg 'Error establishing 
code to compute <flag>' ‘Error 
in ckFlag Click Handler' 16 


From the above listing, it’s apparent that the instance 
doesn't matter. This is the best of all worlds! The reason 
for this is the function ComputeFlag, which computes the 
“flag” argument when any ckFlag control is checked. 
The Compute Flag code is placed in the data property of 
the flag label, IFlag, by the make function: 


[130] wSelf<Win '1lFlag.New' 'Label' 

[131] Win “caption! 'flag = 0' 

[132] Win '.where' 8.5 64 TS T2 

[133] 

..-(Internal documentation omitted) 

[155] data+'Vflag+ComputeFlag 
call;0I0;flag_enabled;flag_bits; 
value;win_call',OTCNL,'(1] OI0=<1 
ò win_call+«OSPLIT 
''<ckFlag(>,I1,<].value>'' OFMT 
18 © value+Win win_call o 
flag_enabled+((call=1)/0 1111 
111),(call=0)/11101001 
© flag_bits+1 4 256 512 2048 
4096 8192 32768 o 
flag++/flag_enabledxvaluexflag_b 
itsvV' 

[156] 

[157] Win '.data' data 


There is one final example of control object instancing on 
this form, the opCall control. The two radio button 
controls determining which kind of filename call to make 
are instances of opCall. These radio buttons are 
established by the make function much like the ckFlag. 
The Click event handler in this case really does depend 
on the instance: 


fmCallGetFileName_opCall_Click;Comput 
eFlag;call;caption;flag;flag_ena 
bled;win_call 

[1] ay 
fmCallGetFileName_opCall_Click - 
Set variant to call 

[2] aV Calls: Win Wmsg 


[16] a instance: 1 = Open FileName; 2 
= SaveAs FileName 

[17] 

[18] call+2-Win '.instance' 

[19] 
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[20] caption<'R <- [flag] 
WGet',(,€call=0 1)#2 
Lo'SaveOpen'),'FileName (dir 
filename ext title filters 
findex readonly )' 


The instance reference in line 18 depends on the context 
of this event handler to return the correct instance. We 
can not explicitly name the control instance to reference, 
a classic catch-22. 


By the way, I can find no way to query the set of 
instances of a control. I might have expected the 
expression 


Win'opCall[].instance' 


to do so, but instead this causes an Undefined Object 
error. 


Next Month 


A number of items remain open: for example, what about 
forms instancing; and how do you make make functions. 
Forms instancing in my beta release system has a 
problem, but the production v5.1 has just arrived today, 
and I’m assured that forms instancing works in that 
release. Next month we'll cover forms instancing, and 
perhaps a few other topics having to do with the creation 
process, including make functions, a powerful way to 
create forms. 





A EXTENSION NOTES 
by Gregg Taylor 
TOPIC: Encoding/decoding Boolean flags 


Working with Boolean data is hard not to do. Branching, 
selecting, comparing, and expanding all use Boolean 
data. APL allows us (in most systems) to store this type 
of data in such a manner that it really only takes one bit 
per data element, plus the overhead needed to store the 
header information for the variable. It's hard to beat 
Boolean data on storage requirements; nevertheless we 
often see Boolean data converted to other data types, 
using a variety of schemes. 


You may be led to inquire as to why this is done. With 


some special insight, you may be able to take advantage 
of some knowledge that you could be missing or some 
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trick that comes with one of these coding methods. This 
question has bothered me somewhat. especially since I 
have never been privy to the subtleties surrounding these 
methods. So, I thought I would conduct my own 
investigations to determine what the relative advantages, 
and disadvantages, of some of these techniques may be. 


For those APL interpreters that don't support a true 
Boolean (bit) data type, it's obvious that combining 
several zeros (0) and ones (1) of the integer data type into 
a single integer (or even a floating point number) is 
going to save space. If you run on an interpreter that does 
not support the Boolean data type, you should be aware 
that there is no space advantage to Boolean arrays, only 
the functional advantages of selecting, comparing, etc. 


The most common technique that I have come across for 
encoding Boolean data simply uses decode (1) with a 
scalar left argument of two (2). This converts a Boolean 
(base-2) array into a decimal (base-10) array. A few 
examples follow: 


2 ks 1 0 0 T01 


37 
O+AA+3 3p1 0 11 
101 
110 
111 
21 AA a DOWN THE COLUMNS 
735 


For three or four Boolean values, this is a convenient way 
to create an index. I use this technique to simplify 
branching -- it effectively combines all of the conditions 
into a single number, which can then be used to index 
into a vector of line labels. (This is another instance of 
the utility of creating a table of possibilities, as 
mentioned in last month's article. However, as explained 
there, this can get tedious if the table gets at all large.) 


Where this technique is seen quite often is in the access 
control matrix of file systems that provide many levels of 
access. In this instance, there are multiple capabilities 
that may be granted (1) or not (0), and the total 
configuration of these privileges is represented as a 
single number. I can guess that the designers of these 
access control matrices were interested in having a 
matrix with a "manageable" number of elements, as well 
as one that would not grow with the addition of (future) 
capabilities. Combining this with the realization that 
these matrices also contain other integer or floating point 
numbers, so that the Boolean data type would be lost to 
these other types, it's little wonder that this method was 
chosen. The lessons to be learned here are: 
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a) the space advantage of Booleans is lost when 
they are combined with other data types; 

b) encoding allows for future expansion without 
affecting array size; and 

c) keeping multiple rows (or columns) of integer 
data can be cumbersome. 


The down side to this method is the difficulty of 
discerning whether a given flag is set "on" or "off". For 
instance, how easy is it to "see" if the fifth flag (from 
which end?) in the following numbers is set on or off: 
23456, 65432, 80049? I can't do those calculations 
without a little help. A program that incorporates the 
following steps is needed: 


AA+23456 65432 80049 
a WHICH POSITION ARE WE LOOKING 
FOR? 
POSN<5 
A ENCODE THE NUMBERS. 
RES«( POSNp2)TAA 
a THE TOP ROW TELLS WHAT WE WANT. 
RES<+( pAA)pRES 
RES 
O 1 1 


These steps should be put into a program and generalized 
to take data of any rank and perhaps accommodate 
several flag positions. The point is, there is some work 
that needs to be done to get back information about any 
particular capability. 


Another coding scheme converts a Boolean array into a 
character array, typically using elements from the atomic 
vector, DAV. In this method, you may not combine more 
than eight elements at a time (since a character is usually 
an eight bit byte); they are combined, as above, with 
decode (1); and the result is used as an index into DAV. 
Hence, given Boolean matrix BOOLMAT: 


OUI0<0 
a USING APL2 NOTATION 
RES«QAV (218+ (OIO] BOOLMAT] 


Using this technique is about as space efficient as using 
the raw Boolean data, especially if the data can be easily 
grouped into eight bit segments. However, just like the 
base two encoding, you have to break the data back down 
into its Boolean components to discover information 
about individual Boolean elements. (Use DAV 1 RES or 
OAF RES in APL2 as the first step in getting back to the 
Boolean data, then use the base-2 method above for the 
‘rest of the conversion.) 





June, 1993 





This character encoding has two places where I have 
found it to be very useful. The first is where the data have 
to be written out to a non-APL file, e.g. as a DOS, CMS, 
or MVS native "flat" file. In these files a one (1) or a zero 
(0) is converted to a character one ("1") or character zero 
("0") to be placed in the file. By combining (up to) eight 
at a time, you can decrease the file space by a factor of 
eight. The other application for which this comes in 
handy is when you have to convert an eight bit protocol 
(for example) to a six bit protocol (say). This application 
varies a bit from the stated parameters of Boolean flag 
data, but when working with modems, signal processing, 
and the like, the same coding techniques come in really 
handy. 


The coding techniques just discussed suffer from their 
inability to quickly determine whether a particular flag 
has been set (that is, there is a fair amount of processing 
required). But there is a coding scheme that is more 
efficient in this respect, but loses significantly in terms of 
data storage. If you've heard anything about encryption 
techniques of the last few years, you have probably come 
across the use of very large prime numbers to encrypt 
data. On a much smaller scale, we can use primes to 
encode our data. (While you can resort to using a prime 
number generating program, for practical purposes it will 
suffice to merely keep a vector of the first few primes 
with which to work.) This technique works something 
like this: 


PRIMES<2 3 5 7 11 13 17 19 23 29 
BOOLVEC+1 0101 
CODE+ x/ BOOLVEC/( pBOOLVEC )+PRIMES 
CODE 

110 


While it's still not very obvious whether a particular flag 
is on or off, the code to determine this does get simpler: 


RES+«0=(5>PRIMES )|CODE 


In other words, if the number is a multiple of the fifth 
prime (that is, its residue is zero), then that flag is set on. 
As you have probably already figured out, these numbers 
can get large, and hence into the realm of floating point 
numbers (8 byte). This is quite a jump in size. Still, if 
your algorithm employs relatively few such numbers, but 
tests the flags frequently, this approach may have some 
value. 


A burning question still remains: why not just use the 
Boolean array of flags? We have seen that there are cases 
in which encoding data has its uses, but when it comes 
down to raw, in-core functionality and compactness, it's 
hard to beat the simple Boolean array. With the 
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generalized arrays of the newer interpreters there are 
other ways in which the Boolean data may be segmented: 
it's fun to get creative. But it's incredibly difficult to 
improve on the simple Boolean data array for space and 
speed. 


Which brings me to my final point. Sometimes I wonder 
whether coding techniques are employed for valid 
purposes. Just because a lot of Boolean numbers can be 
converted to another form, this in no way implies it 
should be. Yet I'm sure I've seen this kind of data 
conversion for all the wrong reasons. Carefully consider 
why you convert your data back and forth. Maybe it's as 
valid as some of the reasons shown above. But if it isn't, 
you are wasting a lot a time and space for naught. 


WORKING WITH Manugistics’ APLWIN 


Todd B. Marshall 
Conroe, Texas 


[This is the first part of a two-part article. The second 
part will appear in the July issue of this newsletter. -Ed] 


The Windows API (Application Programmers Interface) 
is a collection of programs, macros, and constants that 
grant you access to the myriad of code Microsoft has 
produced trying to match the Apple Macintosh. The 
programs are written primarily for access using the C or 
C++ programming languages. 


Microsoft has finally made the services available to the 
dumber and lazier of us through their Visual Basic 
product, now at version 3. Manugistics is attempting to 
keep pace with their APLGUI ( APL Graphical User 
Interface) product which began shipping with their 
APL*PLUS II/386 Version 5. APLGUI is about to get a 
cleansing with Version 5.1 now being released. 


But way back with about version APL*PLUS II/386 
V3.5, Manugistics began to open APL up to the Windows 
API with their APLWIN product. It came out and just 
kind of sat there. I don't know if anybody developed 
anything using it. It was slow. It was clumsy. And I 
guess it just wasn't really worth the trouble. Now, about 
two years later I am making use of it to learn the 
Windows API. Hopefully, armed with knowledge at this 
level, I will be able to do with APL and Windows what I 
have been able to do with APL and TUI (Textual User 
Interface)... put the dazzle on people. 
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Beginning with this article I will present examples of 
how to use the APLWIN product. If you're going to try 
this at home, I think you'll need the following: 


Manugistics APL*PLUS II/386 V5.0 or greater. 


A copy of Programming Windows 3.1 by Charles 
Petzold, Microsoft press. If you have a C compiler 


you might want to order the disk for the book which 
saves you typing in all the sample code. 


The Microsoft Windows 3.1 Programmer's Reference 
Library. If you don't want to buy the whole set you 


need at least Volume 2: Functions and Volume 
3:Messages, Structures, and Macros. 


If you have Borland's C++ 3.1 and Application 
Frameworks, you get all the Windows API references 


you need with that package. 


Most APL programmers don't have these resources and 
aren't inclined to acquire them. Hopefully I can present 
the concepts clearly enough that something can be gained 
just by reading along. 


Programming Windows 3.x by Petzold seems to be the 
most popular entry point to the Windows API for 
programmers. While the SDK (Software Development . 
Kit) Guide to Programming and Programmer's Reference 
volumes cover all the necessary material, Petzold 
presents the material using examples and explaining the 
new concepts they present. Petzold's book approaches 
the Windows API from the "C" programming 
environment. 


Manugistics has done what I believe is an elegant job of 
connecting the APL environment to the Windows API. 
After a couple of missteps they now have a strategy that 
maintains the Windows interface syntax without a huge 
performance penalty. 


Being Object Oriented, Windows supports a message 
based programming strategy. To you and me, this means 
that when our function is called (by whom we need not 
be concerned) there is message information we must 
decipher to know what to do. The windows message 
layout is pretty simple: handle; message number; word 
parameter; double word parameter. 


The "handle" is the unique number windows gives to 
each window. The "message number" is the unique 
number windows gives to each message type. The 
"word" and "double word" parameters are arguments 
meaningful to that message type. 
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The numbers for all the messages are defined in the 
windows header file (WINDOWS.H). The information 
allows you to write symbolic code using meaningful 
names. For example, in the WINDOWS.H file you will 
find the word WM_PAINT defined as 0x000F which is 
message number 15. 


When you write a program to handle the WM_ PAINT 
message, you could look for message number equal to 15: 
but your code is easier to read if it references 
"WM_PAINT". The "C" compiler binds 15 to your 
WM_PAINT references at compile time. APLWIN must 
do it at run time. Further, the "C" compiler need not 
maintain any knowledge of WM_PAINT after binding 
occurs because it knows all references will be numeric. 
On the other hand, APLWIN must be able to recognize 
references to both WM_PAINT and 15 because it can't 
know which reference the programmer will be using. 


APLWIN obtains the information it needs to do these 
translations in a definitions file (APLWDEF.ADF) that 
you associate with your application. APLWDEF.ADF is 
a compiled version of the information you will find in the 
APLWDEF.INI file. The APLWDEF.INI file sort of 
corresponds to the WINDOWS.H file used by the "C" 
compiler. You can look into the [constant] section of the 
APLWDEF. INI file and find the line 
WM_PAINT=0x000F. 


If you look into the APLWDEF-.INI file for WM_PAINT, 
you probably found it in the [Pattern WP] section before 
finding it in the [Constant] section. Here's where I think 
Manugistics has done something very slick. Remember I 
said after the message number, the message contains a 
word and double word parameter. And I said these have 
different meanings for different message types. The 
layout you see in the [Pattern WP] section tells you what 
these meanings are. For example, in the [Pattern WP] 
section you will find: 


WM_PAINT=(HW hwnd, ~W=) 


This is the "layout" for the WM_PAINT message. 
Reading left to right: HW hwnd (the one word handle 
for the window); ~W= (the one word message 
reference...put WM_PAINT where you see the = sign). 


When your function gets called by windows, you will find 
these arguments in a global variable "w_args" laid out as 
specified above. w_args is a nested array. The first item 
is "hwnd". The tilde ( ~ ) of ~W= says this argument is 
not included in w_args. There are no other arguments. 
So from this we know that if we get a WM PAINT 
message, w_args will contain "hwnd" and that's all. 
Since it is a scalar, it won't be nested. 
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Microsoft calls this method of parsing out the arguments 
"message cracking". In the olden days programmers had 
to do this themselves. Now Microsoft delivers a 
collection of macros they call "message crackers" that 
you can reference in your "C" code making it much more 
consistent and readable. It also will make it easier to 
make the transition from 16-bit Windows to 32-bit 
Windows. Manugistics allows you to use an "ASIS" 
(read "as is") option when you define filters if you want 
to do your own argument parsing. Many of their 
examples use this old-fashioned technique. 


So what are filters? 


"C" being a compiled language, allows API references to 
be bound (symbolic references become internal 
references) at compile time. APL, being an interpretive 
language, waits until execution time to bind the 
references. Normal Windows programming involves 
doing a few setup things and then hanging in a loop 
waiting for messages. The "C" code that does this is: 


while (GetMessage (&msg, NULL, 0, 0)) 
{ 
TranslateMessage (&msg); 
DispatchMessage (&msg); 
} 


return msg.wParam; 


This will loop as long as GetMessage returns a non-zero 
value. GetMessage will return a non-zero result until it 
retrieves a WM_QUIT message. A WM_QUIT message 
is generated when the application calls PostQuitMessage. 
We're getting real close to needing to look at code here. 


APL would die if it had to run this loop every time 
something happens. Just move the mouse two inches and 
you could generate a hundred messages. Ah! what to 
do?...another stroke of Manugistics genius. They put the 
loop into code written in "C". There it runs as fast as 
anyone else's code written in "C". This code they call the 
"Agent". 


The Agent is a separate program that actually gets called 
by windows and then calls the APL interpreter. The APL 
interpreter communicates with the agent through some 
"name associated" functions which you can copy from the 
APLWIN workspace. 


Setting up the environment 
If you know what you're doing, just get the functions 


HELLOWIN and THISFN into a workspace that can run 
windows programs. 
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If you don't know what you're doing, do the following: 6. Invoke W_LX 


l. Install APL*PLUS II/386 under windows as 7. Save workspace as TESTWIN 


described in the Manugistics Documentation 


THISFN found at the end of this article. 


3. Save the workspace as HELLOWIN 


5. Copy HELLOWIN and THISFN from HELLOWIN 
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Then type HELLOWIN 0 and the demonstration program 
2. Enter the code for the functions HELLOWIN and is off and running. It presents the window with the 


greeting Hello Windows! in the center. You can resize 


the window and see it repaint. When you're done, click 


the System Menu Button (upper left corner of the 


window) and click on Close (or just use the ALT-F4 
4. Load APLWIN accelerator combination). 


[continued next month] 





The Code 


The following is the APL code which produces the Hello Windows Screen. The code was taken almost word for word 
from Charles Petzold's example HELLOWIN in his book Programming Windows 3.0. This is the leading text for leaning 


windows programming in "C". 


I have included the "C" code as comments for ready comparison to the APL 


correspondence. There are a number of optimizations that can be made to the code to make it more compact and run 
faster. These will be covered in later treatments. 


The HELLOWIN function 


While this function and examples to follow are quite long, they are structured so as to be easily deciphered. The general 
philosophy followed is to maintain code in a single function as long as it is used only by a single function. Comments are 
used sparingly in deference to making the code itself readable and understandable. 


v 
[1] 
[2] 
[3] 
[4] 
[5] 
[6] 
[7] 
[8] 
[9] 
[10] 
[11] 
[12] 
[13] 
[14] 
[15] 
[16] 
[17] 
[18] 
[19] 
[20] 
[21] 
[22] 
[23] 
[24] 
[25] 
[26] 
[27] 
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rc-HELLOWIN MSG 
AAPL HelloWin program corresponding to Petzold's HELLOWIN.C 


ABranch to Service Routine if MSG # 0 
> (O0#MSG) /MSG 


szAppName+'HelloWin',%?1000 
>STARTU P | 


STARTUP: 

AInitialize this window 

Aint PASCAL WinMain (HANDLE hInstance, HANDLE hPrevInstance, 
A LPSTR lpszCmdParam, int nCmdShow) 
(hInstance hPrevInstance lpszCmdParam nCmdShow)+-W Init 


ASet up the message handling filter 
W FP 'WP' 

"WM PAINT' W_FP THISFN WM PAINT 

"WM DESTROY' W FP THISFN WM DESTROY 

WndProc-W CreateFilter w fp 


ARegister this window class 


A wndclass.style = CS_HREDRAW | CS _VREDRAW ; 
WA ("CS HREDRAW CS _VREDRAW' ) 
A wndclass.lpfnWndproc = WndProc; 
WA WndProc 
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A 
W RegisterClass 


wndclass. 
WA 


wndclass. 


W A 


wndclass 
WA 


wndclass 
W A 


wndclass 
W A 


wndclass 
WA 


wndclass 
WA 
wndclass 
W A 


.hbrBackground = GetStockObject 


. lpszMenuName 


chClsExtra = 0; 
0 
cbhbWndExtra = 0; 
0 
-hInstance = hInstance 
hInstance 
.hIcon = LoadIcon (NULL, IDI APPLICATION); 
c('Load_ IDI' 'IDI_APPLICATION' ) 
-hCursor = LoadCursor (NULL, IDC ARROW) ; 


©('Load IDC' "IDC ARROW' ) 


(WHITE BRUSH) ; 
c('GetStockObject' 'WHITE BRUSH') 


NULL; 
0 


»-lpszClassName = szAppName; 


szAppName 


RegisterClass (&wndclass) ; 


wndclass« © WA 9% 


Create the Window 


"CreateWindow' 


A 0 
A 0 


A hInstance 


WAO 
hwnd-W Call 8 wWwASs 


A 

A szAppName 

A 'The Hello Program' 
A 'WS_ OVERLAPPEDWINDOW' 
A '"CW_USEDEFAULT' 

A '"CW_USEDEFAULT' 

A "CW _USEDEFAULT' 

A '"CW USEDEFAULT' 


//window class name 
//window caption 
//window style 
//initial x position 
//initial y position 
//initial x size 
//initial y size 
//parent window handle 
//window menu handle 
//program instance handle 
//creation parameters 


D D) D D D D D D D D D 


AShow the Window and Paint it 


A 


t-w Call 


A 


(' 


ShowWindow (hwnd, nCmdShow) ; 
ShowWindow' hwnd nCmdShow) 
UpdateWindow (hwnd) ; 


W Call ('UpdateWindow' hwnd) 


AWait for things to happen 
re-w Wait 


A while (GetMessage (&msg, NULL, 0, 0)) 
A { 

A TranslateMessage (&msg) ; 

A DispatchMessage (&msg) ; 

A } 


w z-0 © ~Exit A return msg.wParam; 
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[84] ASSssssse==SSSSSeeSSSSSSSSSSSSSe525S5 SSS SSS SSS SSS ESS S555 eSSS=25=5= 
[85] AMessage Service Routines 
[86] A---------------------------------------------------------------- 
[87] A switch (message) 

[88] A { 

[89] 

[90] A case WM_PAINT: 

[91] WM_PAINT: 

[92] hwnd-w args 

[93] A hdc = BeginPaint (hwnd, &ps); 

[94] (hdc ps) + W Call ('BeginPaint' hwnd ae) 

[95] A GetClientRect (hwnd, é&rect) ; 
[96] (rect) + W Call ('GetClientRect' hwnd v2 ) 

[97] 

[98] A DrawText (hdc, 'Hello, Windows!",-1,érect, 

[99] A DT _ SINGLELINE | DT Center | DT _VCENTER) ; 
[100] W_A 'DrawText' hdc 'Hello, Windows!' `l rect 

[101] WA "DT SINGLELINE DT CENTER DT VCENTER' 
[102] tW Call OWA S 

[103] 

[104] A EndPaint (hwnd, &ps) ; 


[105] t-W Call 'EndPaint' hwnd ps 
[106] 

[107] A return 0; 

[108] w z-0 9% ~Exit 


[109] 

[110] A---------~-----------------------------------------~+-------+--+--- 
[111] aA case WM DESTROY: | 

[112] WM DESTROY: . 

[113] A PostQuitMessage (0) 


[114] re-W_ Call'PostQuitMessage' 0 

[115] A return 0; 

[116] w 2-0 © >Exit 

[117] 

(118) Asssssss2SSS SSS SSS SSeS s esses ssssSSSseeSSeeSS ESS SSS SSS SSE ESSE SSS== 
[119] Exit:-0 


THISFN 
This is the only function used by HELLOWIN which is not part of the APLWIN suite of functions. THISFN allows most 
of the Petzold examples to be translated into a single APL function. The technique allows recursion into the main 
function to handle messages as dictated by the filter specifications. 

v R-THISFN MSG 
[1] AReturn string with calling function name followed by MSG 


[2] Ae.g. If in MYFUN you have a line label named WM COMMAND, and 
[3] A it is on line 123, and within MYFUN you have a 

[4] A statement like: 

[5] A X - THISFN WM COMMAND 

[6] A then X will contain: 

[7] A 'MYFUN 123' 

[8] A 

[9] A If this gets executed by the agent using the recursive style 
[10] aA of writing windows programs with automatic switch statements 
[11] A you will enter the function MYFUN and branch to line 123 which 
[12] A is the line with the WM COMMAND label. 

[13] a 


[14] R-USI[(2;]9R-("1+Rui'[') TR 
[15] R-R,' ', MSG 


i et 
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o OOF: OBJECT ORIENTED FILING 


for MANUGISTICS’ APL*PLUS 








To CASPER COURT 12 OBJECT FILE FUNCTIONS 
CONROE. TX 77302 38 DERIVED OBJECT FUNCTIONS 
14 APPLICATION MANAGEMENT FUNCTIONS 
(409)273-2100 32 SHARE FLE FUNCTIONS 
14 NATIVE FILE FUNCTIONS 
D ]. A N < 11 ANCILLARY FUNCTIONS 
we vo” o 00 PAGE REFERENCE AND TUTORIAL 


PRIMITIVE 
WRAPPER FUNCTIONS Othe r 
ae anet Functions 


Sharefile í 
a E AUXILIARY PROGRAM LIBRARY = DATA 


PNE E E wee ee 5 eRe ees 














2BDUMP : | -AUXG PCM LBC] 


COMPRESS : AUXON POMON UBCN 
FCREATE 
'AUXFLE PCMFILE UBE 
, AUXGET | | . 
| 'AUXNAMES  PGMNAMES = LIBNAMES ` 
| QOFPGMGET ` AUXPGMGET | 
| | AUXPGMGETL © PGMGETL 
OOFPGMPUT = AUXPGMPUT ` PGMPUT LBPUT 
OOPUT ATO | 
OOFRMV = AUXRMV, ` PGMRMY 
-AUXTS 
: ~ PGMRUN 


YES! Please sead me copies of eee 


















een "E 
SHARE AART NATIVE : L ee enn 
o | FUNCTIONS money order eaclesed with this order form 
Te | i (WA pay letia sa Peepal MaA T orders!) 






(_] APLPLUS PC version 11 


LJ 3-1727. [] s-174° 
[ understand that if I am not fully satisfied, I may retam the software within 
15 days, without obligation, and KISS will cance! ary bill immediately. 











SouthWest APL Users' Group 
Membership Application 

















Name: _ 

Company: 

Address: 

Telephone: (homc) (work) 
E-mail: 

Membership fees, per year: U.S.A. ieee cccecssssceceececeseentsseeees $12. 


Non - U.S.A. postal supplement ..0.0...0000002.. S6. 
Petri Donil Omosa nea 


Please mail this application and the applicable ducs to: Stuart Yarus 

(Checks should be made pavable to "SWAPL") P. O. Box 210367 
Bedford, Texas 76095 
U. S. A. 


Stuart Yarus, Editor 
SWAPL Newsletter 
P. O. Box 210367 
Bedford, TX 76095 
U. S. A. 


*** Address Correction Requested *** 








A red dot next to your name indicates that this is your 
LAST newsletter. Please renew your membership today! 





